1. Field of the Invention
The present invention relates to a portal system and, more particularly, to the automated creation of portlets configured for inter-portlet communication.
2. Description of the Related Art
A portal is a Web site that serves as a starting point to access information and applications within a networked computing environment. Typically, a portal has an architecture that provides standard functions including, but not limited to, security, authorization, authentication, aggregation, caching, user management, enrollment, rendering, and the like. The portal provides the infrastructure necessary for aggregating other applications or application components called portlets. Portlets are also known by other names, depending upon the manufacturer or vendor, such as Web parts, iViews, or the like. A typical embodiment of this type of architecture includes an application programming interface (API) for integrating applications. Accordingly, portlets from different vendors can be used so long as such portlets are configured to utilize the API provided by the portal. For example, the WebSphere Portal family of products available from International Business Machines Corporation of Armonk, N.Y. (IBM) supports such computing environments.
Portlets are reusable components or applications. Within a portal environment, portlets provide access to Web-based content, applications, and other resources. Web pages, applications, and syndicated content feeds, for example, can be accessed through portlets. From a user perspective, a portlet is a window located in a portal page that provides a specific service or items of information. From an application development perspective, portlet code comprises pluggable modules that are designed to run inside a portlet container of a portal service.
Modem development tools provide several mechanisms to help developers create portlets. The developer typically is guided through a wizard-type process where the development tool asks the developer to specify or describe the data that is to be queried or otherwise manipulated by the portlet(s) being created. The metadata provided by the developer describes the structure of the data that is to be queried. Once this information is manually specified by the developer to the development tool, one or more portlets can be created automatically which can query or manipulate the underlying data.
The resulting portlets can perform one or more tasks in terms of querying the underlying data. These portlets function largely independently of one another and, as such, lack inter-portlet communication capability. It is the responsibility of the developer to manually specify the communication links through which the portlets will communicate with one another. For example, if a first portlet displays orders for an organization and a second portlet displays details for the orders, the first and second portlets would have to be coupled to allow data to be sent from one portlet to the other. Coupling allows an end user to view order information and order detail information for the same order without having to manually initiate a related query in each portlet, i.e. the order portlet and an order detail portlet.
Portal environments such as IBM WebSphere provide mechanisms for coupling portlets. One mechanism is referred to as a “click-to-action” control where information from one portlet is used to drive an action in a second portlet. While working in the portal development environment, the developer can select one of the click-to-action icons displayed in the source portlet. The source portlet refers to the portlet that will drive the action in the second portlet. Each click-to-action control is associated with a typed data item, or property. Upon selection of a click-to-action icon, a menu of actions which can process the associated property can be presented. The actions in the menu can be invoked with respect to one or more target portlets. A target portlet is a portlet that executes an action responsive to the source portlet. The target portlet is driven by the source portlet. The source and target portlets typically are displayed upon the same portal page, although this is not a strict requirement. The user can select an action from the menu, which causes code to be executed on the source portlet such that during operation, i.e. at runtime, a request is delivered from the source portlet to the target portlet to perform the selected action. The property associated with the click-to-action control is passed to the target portlet as an input to the action.
Another mechanism for communicatively linking portlets can be through what are referred to as “wires”. A wire refers to a persistent association between a property in a source portlet and an action to be performed in a target portlet. When an event occurs that affects the property of a wire, the action associated with that property is triggered in the target portlet. Further information regarding inter-portlet communication can be found in IBM Rational Application Developer V6 Portlet Application Development and Portal Tools (August 2005).
While portlets presently provide a high degree of functionality, it would be beneficial to provide a means by which portlets having inter-portlet communication capabilities can be created in a more automated fashion.